【7月7日は創立記念日！】「ブログを書く」ということ

創立記念日投稿のポエムです

#ブログ

#カルチャー

#ポエム

丸毛篤史

2020.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

クラスメソッド AWS 事業本部コンサルティング部の丸毛（まるも）です。

7月7日はクラスメソッドの創立記念日ということで、今日は「ブログを書く」ということについて、普段はあまり書かないポエムとしてしたためたいと思います。

22,000 本のブログのはじまり

執筆時点で公開済み本数を確認したところ、「22,040 本」となっていました。

Developers.IO は2011年7月1日の福田の記事にはじまり、記念すべき技術ブログ 1 本目は社長の横田による S3 の記事でした。

私はクラスメソッド在籍2年7ヶ月目になったわけですが、この記事で 186 本目になります。（更新にラグがあるのでチョット少なく見えているのは、ご愛嬌）

16期（2019/7/1〜2020/6/30）では念願の年間 100 本（102本）を達成することも出来ました。自分なりに「よく書いたな・・・」と感じるものの、Developers.IO 全体からすれば 1 % に満たないことを知ると、先人たちの積み重ねた功績の大きさに頭がさがります。

なぜ書くのか

ブログは「クラスメソッドのカルチャー」です。

横田の記事にはじまり、横田が書くならと現在の部長陣をはじめとするクラスメソッドの顔とも言える先輩たちも書きはじめ、その背中をみたメンバーが「じゃぁ俺らも書こうか」と。（私が在籍する以前なので、伝え聞いた話です）。特に強制されるでもなく、そういった連鎖がクラスメソッドのカルチャーだと私は思っています。

特定のメンバーが書く企業ブログはそれなりにあると思いますが、社員全体が「ブログを書く人」であることがクラスメソッドなんです。故に、なぜ書くのかと聞かれれば・・・

「クラスメソッドの人だから」

が答えです。

何のために書くのか

「クラスメソッドだから」だと誰の参考にもならないので、もう少し汎用的な視点で書きます。

自分のために書く

ブログを書くことは様々な面で自分のためになるでしょう。

知識の整理

学んだことを記事にまとめることで、散らばった知識を整理し、腹落ちさせることができます。

スキルアップ

ブログのネタのために新しい技術を試すことは往々にしてあります。結果的に新しいインプットのきっかけとなり、スキルアップへと繋がります。

備忘録として

毎度まいど調べてることってないでしょうか。たまに使うけど、すぐ忘れる。覚えきれない（たまに使うコードとか、AWS サービスとか）また忘れるであろう自分のために書き残すことも多々あります。

フィードバック

ブログを書くことで Twitter や、はてブでコメントをいただくことも多々あります。そのなかにはいわゆる「マサカリ」と呼ばれるものもありますが、自分が見落としていた視点の気付きにもなり、知識を高めてくれるありがたいフィードバックを得ることができます。

セルフブランディング

興味のある技術についてどんどん発信することはセルフブランディングになります。発信し続けることで登壇依頼や、執筆依頼が舞い込んでき、その分野で知られる存在になることも少なくありません。

誰かのために書く

お客様のために

あまり真似できるものではないかもしれませんが、弊社の場合、案件のなかでお客様よりいただいた質問であったり、構成について詳細な説明をするために、特定されるような情報は削ったうえでブログにして回答する、といったことはよくあります。

未来のお客様のために

いまは繋がりがなくとも、記事をきっかけにお問い合わせをいただくこともあります。企業サイトで「サービス内容：ｘｘの設計、構築支援」と載せるだけの企業と、具体的な情報を発信している企業とどちらが「お。この会社は詳しそうだな」と思っていただけるでしょうか。

同じ技術をもとめる誰かのために

クラスメソッドの企業理念には「すべての人々の創造活動に貢献し続ける。」とあります。お客様としての繋がりはなくとも、どこかで誰かの役にたてるように情報を発信しています。

玄人が好むようなゴリゴリの技術記事だけでなく、これからエンジニアとして駆け出すビギナーの方に向けにも。すべての読者が AWS を深く使い込んでるわけではありませんし、むしろこれからはじめたいという方のほうが母数としては多いのではないでしょうか。

「今さらこんな初歩的な記事なんて需要ある・・・？」

と思う必要はまったくありません。

どうやって書いてるのか

書きたいときに書き、出したいときに出す

企業が外部に情報発信する場合、一般的にはレビューがあったりするでしょうか？クラスメソッドでは一切のレビューはありません。書きたい人が書きたいときに書き、出したいときに出す。

投稿する前に、いろんなところから「あーだ、こーだ」と言われると、往々にして書くモチベーションが下がります。レビューを通すために加筆したり、受け取り方によってリスクがあるという指摘のために言い回しを考え直したり。レビューをとおすための時間ばかり増え、あるとき気づきます。「あれ。これ誰のために書いてんだっけ。。」と。

そうなってしまうと、なかなか「じゃぁ次も書こう」というモチベーションにはならないし、そういう背中を見てるメンバーから「俺も書こう」という連鎖はきっと生まれません。

間違ったこと書いたりしないの？

あります。投稿者の認識違いによって、間違ったことを書くことも時々あります。もし間違いがあれば、「ごめんなさい、誤りがありました」と言って、訂正すれば良いんです。いつでも修正が効くのがブログの良いところですね。（書籍など物理的なアウトプットだと、そうは行きませんが・・・）

誤字、脱字程度は頻繁にあります。ただ、概ね社内の slack で「typo のお知らせ」をいただくことができます。それは Developers.IO の一番の読者はメンバーだからです。間違っていたら誰かが気づいてくれる、そういった安心感もレビューなしで投稿できる要因の 1 つかもしれません。

最低限のルールはある

とはいえ、何でも書いて良いということではありません。クラスメソッドの顔となるブログですので、書かないことのルールはあります。それは批判や、ネガティブな（disった）メッセージングにしないことです。

これは、嘘でも称賛する記事を書くということではありません。例えば特定のサービスを試した「やってみた記事」を書くとします。「あー、ここ使いにくいな」「この機能が足りないんだよな」と思うことはありますが、それを全面に押し出す記事にしないということです。

なるべく、その製品、その機能の良いところを書き、「もっと、こうなっていれば使いやすい」と言い換える、といった配慮をします。「使いにくい」と「こうだったら使いやすい」書いてることは同じですが、読んだ方の印象は違うと思います。（製品、機能の厳しいフィードバックはプライベートな場で。）

いつ書いてるのか

基本的には就業時間中に書いています。「ブログを就業時間に書くの？」と思われるかもしれませんが、ブログはエンジニアにとってのナレッジであり、営業にとっての営業ツールです。多くの企業でも Wiki や社内ドキュメントは就業時間中に書きますよね？それと同じです。

企業にとっての知的財産なわけですから、就業時間中に書くことは至極当然のことだと言えます。

とはいえブログばかり書いてると案件対応が出来なくなりますので、そこは各エンジニアのセルフマネジメントに任せられておりバランスをとってね、ということになります。

私のように退勤後や休日に趣味として書くことも OK です。正直、月 10 本も 20 本も書こうと思うと、プライベートな時間を使って自分のために、という気持ちで書かないと、案件との両立は難しいです。

どんなことを書くのか

Developers.IO を見ていただければ解るかと思いますが、会社からの指示で書くものではなく、エンジニアが興味を持ったもの、書きたいものを書いているので、多種多様・千差万別です。

もしマーケティング戦略ありきで、会社から「この製品について書いてほしい」「このサービスについて書いてほしい」ということであれば、こんなにもカルチャーとして根付いてなかったのだろうと思います。

まずはエンジニアがその製品、サービスについて「ファン」であり、書きたいことを書かせてあげる環境が大事ですね。

また、ジャンル的には「技術ブログ（やってみた系）」が多いですが、re:Invent や AWS Summit でお馴染みの「レポートブログ」であったり、マネジメント向けのビジネスマインド的な内容から、ポエムと言われる「想い」を書いたものまで自由に書いています。

ブログを書くコツってあるの？

私なりに思う、ブログを書くコツを紹介します

継続的に書く

クラスメソッドでは「ブログ筋」なんて言いますが、ブログは書かない時間が続くほど、どんどん書けなくなります。使っていない筋力が衰えるかのように、弱っていくということで、まさに「ブログ筋」ですね。

ブログを書き始めた当初、4 本/月を目標としていましたが、4 本に照準をあわせていると、4 本書くブログ筋しかつきません。今年に入って 10 本/月くらい書くつもりで続けていますが、そうすると 4 本でヒーヒー言うてた自分が嘘のようにブログが書けるようになっています。

常にブログネタを意識してる

調べごとするときも、お客様からの問い合わせも、Twitter などから流れてくる情報も常に「これ、ブログのネタになるんじゃないか」「ブログのネタにするなら、どういう課題を定義して、どうやってまとめようか」みたいなことを常に考えています。

そうすると、いざ書こうとしたときには既にある程度の構成ができているので、短時間で書ききることができます。（といっても平均的に 2〜3時間は掛かってますが。短ければ 1 時間）

ブログを書けば、ブログが書ける

「何言ってんの？」と思いますが、ある技術についてブログを書いてたとします。すると書いてるなかで「あれ？ココって詳細に理解してないな」「ん？このパターンだったらどうなるんだろ」というように理解が曖昧な部分や、新たな疑問がみつかります。つまり、ブログのネタです。

ブログに起こすことで、頭の中の知識が整理され、いままで見えてなかったところが明確になるので、次はその部分を埋めるブログを書けば良いんです。まさに「ブログを書けば、ブログが書ける」ですね。

目標意識しない（ノルマにしない）

コンサルティング部だと月 4 本を目標としていますが、ノルマではありません。（ペナルティがあるわけではない、という意味で）

いくら「ノルマではない」といっても自分が目標達成に縛られすぎると、それは「ノルマ」になります。

ノルマになるとどういうことが起きるかというと、記事のクオリティが下がります。それは内容よりも「数」を取りにいくからです。本当に発信したいことじゃないけど、手頃な技術ネタを探しはじめます。

手頃なネタが悪いわけではないですが、そこに「これを発信したい！」という想いがないと、基本的にクオリティは下がっていくだろう、というのが私の考えです。

なので目標値として持つのは良いですが、縛られすぎないことが大切です。

書く時間を確保する

「空いた時間で書こう」と考える方も多いと思いますが、私はこれは書けないパターンだと思っています。

忙しい業務のなかで「空いた時間」は基本的に無いからです。「空いた時間に書く」というのは優先度を下げるということですので、自分のなかで「書こう」という意思が弱まります。「時間がなかったので仕方ない」がずっと続くだけになるでしょう。

仮に空いた時間で書けたとして、それではブログを書き続けることは出来ません。たまたま時間が空き続けない限り。

もし、本当にブログを書き続けたいのであれば、「ブログを書く時間をまず確保する」。書く時間を確保したうえで、その他の業務をどうやって回すかを考える。これしかないと思います。

えいやー！で投稿する

記事中の技術に関して「あ、あれも説明しとかないと、わからないかな？」「お。これもいるかな？」と細かい点までフォローしはじめると、いつまで経っても投稿できなくなります。それはそれでクオリティとして高くなるので良いことですが、1本の記事で網羅的に書くことは非常に疲れます。1本書き上げるのに非常に労力を使った結果、書かなくなりがちです。

個人的には7割〜8割の完成度で「えいやー！」と割り切って投稿するのもアリだと思っています。フィードバックのコメントで見落としが見つかる場合もあれば、あとから自分で気づくこともあります。そうした場合は「書き足せば良い」と思います。